2. Developer Information

• 2.1 Minimum API Developer Requirements
• 2.2 Payment Gateway: Operational and Maintenance Hours
• 2.3 Security
• 2.4 Parameterised Data
• 2.5 Role– players in the System
• 2.6 Payment Types Accepted

2.1 Minimum API Developer Requirements

1. For PCI compliance the merchant is not permitted to host their own payment page where credit card details are captured.
2. This must be done using the Vodacom Payment page (hosted in Vodacom's secure PCI environment).
3. Payment page templates (such as Amazon Payments, eWay, PayPoint, PayPal, SagePay, WooCommerce, World Pay etc), are not supported.
4. An application developer utilising the Vodacom Payment Page interface must be able to understand and complete the following development steps (at a minimum):
• Construct an HTML form post that conforms to the requirements outlined in 3.1.5 Tokenisation Step 3 – HTTPs Form Post to Payment Gateway.
• Construct an XML or JSON Transaction object that conforms to the requirements outlined in 3.1.3 Tokenisation Step 1: – Create Transaction Object
• Encrypt the transaction object (using a standard Blowfish encryption algorithm), and include it in the HTML form payload (as defined in 3.1.4 Tokenisation Step 2: – Encryption and 4.2 Appendix B: Encryption Algorithms).
• The encryption algorithm can be implemented in a variety of languages that meet your requirements (such as PHP, .NET, Java etc).
• Encrypt various form parameters (using a standard Blowfish encryption algorithm), and compare it with the form and server post-backs from payment gateway (to ensure there is no man–in–the–middle attack), as outlined in 4.3 Appendix C: Control Key)

2.2 Payment Gateway: Operational and Maintenance Hours

2.2.1 QA Environment

Please note that the payment systems undertake maintenance on their QA environment during the following times (SAST):

• 07h00 – 08h00
• 12h00 – 13h00
• 16h00 – 17h00

In addition, please note that scheduled payments are an asynchronous operation with the bank.
Turn–around times for processing scheduled payment batch requests are not guaranteed in any way.
The banks are also not available outside of normal business hours (SAST) for processing scheduled payment requests.

2.2.2 PROD Environment

The PROD environment undertake regular releases for which you will be notified prior to implementations.
The implementation window for these are usually between 23h00–01h00 (SAST).
Please send a request to PSP-ServiceRequests@vodacom.co.za to be included in the distribution list for these release notifications.

In addition, please note that tokenisation and scheduled tokenised payments are an asynchronous operation with the bank.
In production the bank should process batch requests every 15 minutes.
ABSA bank do not process batch card tokenisation or scheduled tokenised payment requests on public holidays or Sundays.
Other banks (such as Nedbank), may differ – please enquire.
Take note, this is a lengthy batch process and runs as scheduled tasks between VFS and the bank.
It should never be relied upon to be returned quickly or included in a synchronous user–journey with the customer.

2.3 Security

2.3.1 Transport Layer Security and Firewall Requirements

• TLS 1.2 is required for all browser access to the hosted pages.
• The Merchant end–points to which payments will respond back to, must be accessible from the PCI Payment Gateway..
  As a consequence firewall rules must be applied to successfully post–back to the Merchant..
  The Merchant end–point must be TLS1.2 compliant and be accessible on the internet..
  Please complete the table below and return it to PSP-ServiceRequests@vodacom.co.za and PSP-OperationsSupport@vodacom.co.za and VFSIntegration@vodacom.co.za in order for the firewall change to be logged..
  Please note that firewall changes at Vodacom require a minimum of 48–hour turn–around time.

• The following payment gateway public addresses must be white–listed on the merchant's firewall, for their corresponding environment in order to receive successful post–backs.

Table 5. Payment Gateway White–List Requirement

Environment	Payments Source Host Name	Payments Source I.P. Address
QA	https://qa.vodacompaymentgateway.co.za	41.1.32.181
UAT	https://uat.vodacompaymentgateway.co.za	41.1.32.182
PROD	https://psp.vodacompaymentgateway.co.za	41.1.32.185

2.3.2 Payload Encryption

• All payloads sent to Vodacom Payment Gateway must be encrypted (see 4.2 Appendix B: Encryption Algorithms: for details)

2.3.3 Control Key

• A Control Key must be used between the merchant and the Vodacom Payment Gateway to detect any tampering with messages exchanged (see 4.3 Appendix C: Control Key for details).

2.4 Parameterised Data

• It is recommended that all fields in various payloads that are marked with a ^ symbol in this documentation, be stored as a run–time configurable parameter in your development.
• The field–values for these objects are subject to change over time, or across environments. This will prevent you from having to release code with new hard–coded values.

2.5 Role Players

2.5.1 Vodacom Payment Gateway

• Secure website hosted in Vodacom secure domain that allows customer to pay for the goods purchased from merchant. Performs the tokenisation of a customer's card and returns a token to the merchant. Processes recurring payments submitted by the merchant for the merchant/customer's token. The Vodacom Recurring payments online documentation can also be found here

2.5.2 Customer

• Defined as a person requesting the payment for goods.

2.5.3 Merchant

• Defined as a business or person that provides the goods to the customer, and the merchant will integrate to the VPG.
• The merchant must meet the conditions listed in the following table.

Table 6. Merchant Prerequisites

Condition Type	Condition Details
Bank Registration	The merchant must have a valid merchant registration for eCommerce transactions with Nedbank (Vodacom Financial Services Bank). ABSA will be the bank used for recurring Payments.
Hosted Pages	Hosted pages belong to the Payment Gateway in this instance. Branding can be applied to the merchant templates for the payment checkout page, and the outcome of the customer payment. For more detail refer to Section 6: Merchant Templates of the Merchant Interface Payments Page specification.
Merchant Configuration	Vodacom Payment Solutions Operations team must configure merchant details on TransSmart. The merchant must be configured with the bank for recurring payments. The following information is required: Merchant Number Terminal ID MCC Merchant Entity Name Merchant Aliases Merchant Bank Account Number Merchant Business Address Recurring Payments: Yes Please send a merchant on–boarding request to VPSonboarding@vodacom.co.za Ensure you request a merchant access form to setup a Payserver technical user required for the integration.
Scheduled Payments	The merchant is responsible for managing the occurrence and scheduling of the recurring payments. The merchant is responsible for the duration and period of the recurring payments and the cancellation or amendments thereof. Take note, this is a lengthy batch process and runs as scheduled tasks between VFS and the bank. It should never be relied upon to be returned quickly or included in a synchronous user-journey with the customer.

2.6 Payment Types

The Vodacom Payment Gateway will accept the following payment types as allowable payment options, which must be configured per merchant:

• Mastercard
• Visa

Please note Vodapay, Masterpass, Diners or Amex payment methods are not allowed for card tokenisation.

Continue

• Continue to 3. Merchant Integration Flow: Card Tokenisation and Tokenised Payments

Return

• Return to Introduction
• Return to Contents